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How to crunch code 

d 

Whenever a BASIC program's source code is compiled, 
the resulting object code is placed in sequential disk 
frames. When the object code is executed, BASIC's 
runtime interpreter scans and processes the object code 
byte by byte, starting with the first frame of object code 
for the program. Whenever the interpreter accesses a 
given frame of object code, and the frame isn't already in 
memory, a frame fault occurs. That is, the running 
program effectively stops and waits for the operating 
system to bring the required frame into memory from 
disk, so that the interpreter can continue. Because 
mechanical disks are rather slow, frame faults can 
drastically degrade system performance. 

Minimizing frame faults means maximizing system 
throughput. That implies that it is desirable to "crunch 
code", or keep object code squeezed into as few disk 
frames as possible. The fewer frames a given BASIC 
program occupies, the fewer frame faults it will cause, 
while more memory will be available for other programs 
trying to run at the same time. 

One quick and easy way to crunch code is to use the (C) 
option when compiling. (The compiler features and 
results discussed here may vary slightly for your 
machine. Consult your compiler's documentation to find 
out exactly what features are available on your system.) 
To allow runtime error messages and the debugger to 
reference line numbers, the compiler normally generates 
one extra byte of object code for each line of source 
code. The (C) option tells the compiler to suppress 
those extra end-of-line bytes. That means a 500-line 
program will save 500 bytes of object code, and occupy 
one less frame of memory. The disadvantage is that line 
numbers won't appear in error messages or be available 
to the debugger, but programmers shouldn't use the 
(C) option on undebugged programs anyway. 

The compiler's (m) map option is another helpful code 
crunching tool, in that it can indicate when crunching is 
worth the effort. The end of the map that is output when 
(M) is used shows what frames of object code are 
generated for what lines of source code. If the last frame 
of object code represents 20 source code lines, it might 
be hard to crunch enough code to squeeze away a 
whole frame. But if only the last two or three source code 
lines overflowed into one whole object frame, there's a 
good chance enough bytes can be squeezed out so 
that the object code shrinks enough to make the last 
(mostly empty) frame drop off. Always compile with the 
(M) option to determine if an attempt at crunching code 
has actually saved any disk frames. 

After using the compiler's (C) option, crunching object 
code becomes much more difficult, and requires 
knowing what kind of object code is generated for a 



























anywhere you've got a PICK-based computer system and a CRT terminal. 
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Higher Education with PROF Software. 

No longer will you be tardy at understanding the PICK database, TCL, 
EDITOR, ACCESS, PROC, and BASIC. With the PROF electronic learning 
system you can master the fundamentals of PICK on your own, at your 
own pace. PROF can be used on site over and over again by DP 
Managers to train new employees without the use of costly seminars. / 
complete PICK education is now available right on your computer syster 


le time to get an education is now! You can order PROF for your PICK, 
icrodata, or Prime INFORMATION™ system by writing or calling us at: 


RESCEMDO Associates, Inc 


350 Joy Road, Suite 9 Redford Township, Michigan 48239 (313) 537-1919 


PROF leads you through simulated, hands-on work 
\ sessions in which you actively participate. You try evi 
B important command and carefully review the way the 
system responds to each. It all happens right on the 
terminal. There is no book to hold in your lap. 


PICK is a registered trademark of PICK systems, Irvine, California 
Prime INFORMATION is a registered trademark of Prime Computer, Inc. 

































Unlock The Secrets 
In Your Computer! 

Pragma (not to be confused with Pragma's Product Profiles) 
is the original 48-page technical journal for Pick users 
published quarterly beginning in August 1982. Each issue is 
packed with software and helpful information, including 
complete and debugged program listings and detailed, 
explanatory articles for readers at all levels of experience. 
Order your Pragma issues today and begin unlocking the 
secrets in your Pick system! 
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given piece of source code. The tool that helps do that 
is the compiler's (A) option, which outputs object code 
in mnemonic form. If your system doesn't offer the (A) 
option, you can use an "uncompiler" like the one 
featured in Pragma #4. Note that although the (a) 
option displays the various object code stack operators 
in hexadecimal, individual object code instruction 
lengths are usually not shown, so code crunchers must 
also be prepared to pick apart object code with verbs like 
dump. Nevertheless, compiling small test programs with 
(A) and then DUMPing the object code can reveal all 
kinds of ways to crunch code, which is how the examples 
presented below were discovered. 

One way to crunch code is to use oconv instead of 
field. For example, the statement x = field (x, 

" * ", 5) generates 17 bytes of object code with our 
compiler, while x = oconv(x, "G5*i") generates only 
13 bytes. However, field is typically much faster than 
oconv, as reported in Pragma #3. (Code crunchers 
soon learn that saving space is almost always a trade-off 
for execution time.) Also, if the third argument to field 
is a variable instead of a constant, it will compile to only 13 
bytes just like oconv! 

field's object code shrinks with variable arguments 
because the compiler generates six bytes of inline code 
for a numeric constant but uses only two bytes for a 
variable reference. That means that statements like _ 
x=33 require ten bytes of code (one byte for the 
interpreter's load opcode, six bytes for the value 33, 
one byte for the store opcode, and two bytes for the 
address of x), while x=y only needs six bytes (three 
bytes each for a variable load and variable store). So if 
a number is going to be used more than twice, assign it 
to a variable and use the variable name instead. For 
example, x=3.14; y- 3.14; z=3.14 requires 30 
bytes of code, but P 1=3.14; X=PI; Y=PI; z=pi 
requires only 28 bytes. However, numbers like 0 and 1 
are handled by the compiler as special cases, so the 
statements x=o and x=i require only four bytes each. 

While numeric constants require six bytes of code, string 
constants only occupy their actual character length plus a 
special end-of-string byte. So while x=33 requires ten 
bytes, x="33" requires only seven bytes (a one-byte 
load opcode, the two-byte string, one end-of-string 
byte, and a three-byte store). However, x="33" saves 
x internally as a string instead of a number, which may 
require more storage space for x in some machines. 
Interestingly, the statement x="33"+o not only saves x 
as a number just like x=33, it also generates one less 
byte of object code! 

Because compiled string constants vary with their length, 
all kinds of trade-offs begin to appear when strings are 
involved. For example, print <string> only requires 
three bytes plus the number of characters in <string>, 
so a statement like print "%" only needs four bytes 


4 





















each time it's used in a program. But the statement 
print "percent" uses ten bytes, so if that statement 
is used repeatedly, it's better to first use x="percent m 
(twelve bytes) and then print x (four bytes) each time. 
A similar example is print @(79, 23) :, which 
generates 16 bytes. If that cursor position appears in lots 
of print statements, use corner=@ (7 6, 23) for 18 
bytes, then print corner: for four bytes each time. 

The space and str functions also offer alternatives to 
string constants. The statement print space () : with 
any numeric constant argument between the 
parentheses will generate only nine bytes of object 
code, so use statements like print " " : for strings 

up to five blanks long, and use space () for longer runs. 
Similarly, print str("*",10) : generates 12 bytes of 
code (and always 12, whenever str's second argument 
is a constant), so use print " * * *" : and the like for 
strings up to eight characters long, and str ( ) for longer 
runs of characters. 


WANTED 

Telemarketing software for Microdata Sequel 9000 

Call (612) 861-4000 or write Metro Sales, Attn: Sandy 
1620 East 78th Street, Richfield, MN 55423 



SO CAL FIELD SERVICE 
WE BUY USED ZEBRAS 


OKM/JONES 

COMPUTER SERVICE 

(714) 953-4351 
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MICRODATA 
EQUIPMENT FOR SALE 

(1) Sequel 9000 VMS System 

• Base system 

• Possibility of selling manufacturing 
software with base system 

Miscellaneous 

1 256 MB Fujitsu Disc 

1 MB Memory 

4 ACLC 

1 5750 Communications Terminal 

5 Prism IV Terminals 

2 Microdata Reality Systems 

• Make offer 

Contact: Priscilla Cain 

Flow Systems, Inc. 

(206) 872-4900 




FREE Back Issues! 


A few back issues of Pragma's Product Profiles are still 
available while supplies last. To receive your FREE 
copies, indicate which issues you need and send a 
stamped, self-addressed envelope to: 


Pragma • 207 Granada Dr. • Aptos CA 95003 


(Allow 1.5 oz. per issue to compute postage.) 
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Issue #21 
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Issue #23 
Issue #24 
Issue #26 
Issue #27 
Issue #28 


Beyond The Power Of The Pick System 
Open Architecture Status Report 
Our Impressions Of The Zebra 750 
Our Third Annual Pick Hardware Survey 
The Wonders Of A Software Upgrade 
A READ Sometimes Fails 
New Pick Book A Disappointment 
Programming For Speed 
How Files Grow 
GA About To Release 3.2 
Beyond The Power Of Pick, Revisited 
How To Find Wasted Disk Space 
The Myth Of Separation^ 

Is BASIC Faster Than Access? 



Although equ statements are convenient shorthand for 
string and numeric constants and array references, they 
don't affect our compiler's code generation at all (except 
for the end-of-line byte after the equ statement itself). 
One exception to this rule is when equ equates a 
variable name with the char function. In that case, the 
compiler actually computes char's value. For example, 
print char ( 7 ) : generates nine bytes of code in 
order to compute and output the bell character at 
execution time. If an assignment statement is used to 
save the value of char and allow convenient multiple 
references, then bell=char (7) requires eleven bytes, 
and each print bell: only requires four bytes. But 
the best approach of all is to use equ bell to 
char (7) , which generates no execution time code at all, 
and each print bell : still only takes four bytes of 
code using a compiler-computed string constant instead 
of a variable load. 




There are many other ways to make the compiler save a 
byte of object code here and there. For example, the 
statement if x < y then print "lt" else 
print "GE" generates one less byte of object code 

than IF X >= Y THEN PRINT "GE" ELSE PRINT 

"LT", even though the two statements are logically 
equivalent. The reason is that in order to compute 
greater-than-or-equal, the compiler generates code that 
computes less-than and negates the result, the negate 
taking the extra byte. Interestingly, x > y generates 
one byte more than x <= y! Similarly, x # y generate; 
one byte more than x = y, while if x then print 
"T" else print "f" requires one less byte than if 

NOT(X) THEN PRINT "F" ELSE PRINT "T". 


Dimensioned and dynamic arrays are another trade-off 
frequently considered by Pick programmers, usually 
because the statements differ so much in execution 
speed. (See Product Profiles #21.) We were interested 
to find that our compiler handles dynamic array 
references slightly more compactly than dimensioned 
array references. For example, the statement 
x (i) =x (i) +1 generates 25 bytes of object code, while 
x<i>=x<i>+i requires only 23 bytes. Unfortunately, 
our compiler didn't do anything special for the newer 
syntax for extract and replace operations: x=y<io> 
compiled exactly like x=extract (y, io, 0,0) , as did 
x<io>=y and x=replace (x, io,*y) . 

One last example is an interesting trade-off we found 
while comparing readv and oconv. The statement 

READV LABEL FROM ID,3 ELSE LABEL="" 

generates 25 bytes of code and requires a prior open 
statement, but label=oconv(id, "T<fiie>;X; ;3") 

performs the exact same function without an open in 
only 15 bytes plus the number of characters in the string 
<f iie>. Unfortunately, benchmarks such as those 
published in Pragma #3 have shown that the oconv 
function executes almost twice as slowly as the readv 
statement. A 
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Tired of waiting for your 
Pick™ computer to SORT or 
SELECT your large data files? 


Need to quickly find any 
attribute? Want to scroll files 
up or down, in any sort order? 


Now you can use B-TREE-P to 
instantly search, sort, and scroll 
any data from any Pick file! 

Now you can instantly look up customers by name, street, Zip code, or any other 
field — not just by customer number. Now you can immediately find inventory 
entries by quantity, cost, or description — not just by part number. Whatever 
files you use, now you can instantly locate and display your data 
any way you want, without having to wait for endless SORTs and SELECTS. 



Immediately display any record in any file just by typing one 
or more starting characters that match any field in the record. 

You can display not only a selected record, but also any 
previous and next records, using any sort order you specify. 

You can jump to any record in a file at any time, then browse 
through the file by scrolling up or down, a record at a time, 
or a page at a time, in any sort order. 

Ask us for a free copy of Product Profiles #24, describing how B-TREE-P was originally 
developed and put to work. As one of Semaphore's programmers says: "We often ask 
ourselves why we waited so long to create B-TREE-P. After using it for our own 
production work, we wonder how we ever got by before without it. A Pick computer 
without B-TREE-P is like a car without wheels". 


B-TREE-P is a proven collection of 
BASIC subprograms for using 
B-trees on Pick computer systems. 
B-trees allow any of the data in any 
of your Pick files to be instantly 
located and displayed in any sort 
order, without having to wait for 
SORT or SELECT commands. 


B-TREE-P and a few minor 
modifications to your existing data 
entry programs are all that is 
necessary for you to immediately 
be able to search, display, and 
browse through your data quickly 
and conveniently. 


Modifications to your existing data 
files are absolutely unnecessary! 



TREE-P 

B-trees for 
* Pick systems. 


Pick is a trademark of Pick Systems. 


B-TREE-P includes all necessary 
BASIC source code for a B-tree 
system that works with any file: 

• Insertion subroutine 

• Deletion subroutine 

• Lookup subroutine 

• Previous/next subroutine 

• Complete instructions 

Plus, you receive the source code 
for a complete demonstration 
system that uses B-TREE-P to 
maintain a name and address file: 

Editor program for creating and 
changing names and addresses. 
Browser program for displaying 
names and addresses. 
Printer program for listing file 
items in order without having to 
wait for a sort. 


Here's how to order: 

Send your name, address, 
telephone number, and your 
check for $395 payable to 
Semaphore Corporation to: 

Semaphore Corporation 
207 Granada Drive 
Aptos, CA 95003 

We'll send you complete 
B-TREE-P source code 
listings and all necessary 
documentation. 

Call us at (408) 688-9200! 

WARNING: B-TREE-P includes a license 
agreement with copy, use, and transfer 
restrictions limiting your use of B-TREE-P to 
one computer at a time. Multi-CPU and OEM 
resale agreements are also available. 
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STREAMING TAPE 


COMMUNICATION 


hard disk 


The 68020-based Altos 3068. 

If you're a PICK software developer or dealer, 
you owe it to yourself to see a demonstration 
of the forty-user Altos 3068. 

Call this number, and well make 
the arrangements. 

(800) ALTOS U.S. 




COMPUTER SYSTEMS 

2641 Orchard Parkway 
San Jose, CA 95134 

WE SUPPORT PICK. 


PICK is a trademark of Pick Systems. 







